Those skilled in the art readily appreciate that there are typically two approaches taken to implementing avionic functions in a flight simulator environment. Techniques involving total software simulation and others incorporating the prime aircraft hardware have previously been employed.
In the context of a flight simulator, simulation is a process whereby the functionality of an avionics system is modeled in software, which is run on the simulator host computer. Typically, the model is based on design data provided to the simulator designer by the avionics manufacturer. For a full fidelity trainer, the model must implement all functionality of the avionic device and run in real time. All signal and data interfaces of the device must also be simulated. Accordingly, the proper data must be obtained from other system simulations and passed to the software model.
Use of the simulation approach provides significant benefits. The model can include Simulator Specific Functions (SSF's) which are not present in the avionic device. For example, if a "freeze" mode of operation were desired to freeze or maintain a frame of the simulator operation, such can readily be attained by simulation, whereas such a "freeze" mode is impossible to attain in normal operation of the aircraft hardware. Additionally, when using the simulation approach, actual aircraft devices, which are often costly and require special interfacing hardware, are not needed. Portions of the avionic device which operate undetected by the pilot and crew being trained, such as diagnostic testing and the like, can be simplified or not modeled at all in the simulation approach.
While the simulation approach has various benefits as discussed above, over the life cycle of the simulator or trainer, the simulation approach has been noted to exhibit serious deficiencies. The most compelling deficiency is the issue of maintaining the simulation concurrent with the aircraft avionic device as it is upgraded with new software revisions. Generally, accurate design data is not available to the simulator designer until the same time frame in which the software update is fielded to the aircraft. During the time that the simulator model update is being designed, implemented, verified for fidelity, and fielded, the crew members are receiving negative training on an outdated simulator. In other words, a significant lag time results between the updating of the flight simulator with respect to updates already employed in the actual aircraft hardware.
The prime hardware incorporation approach to flight simulator development attempts to address the concurrency problem which is significant in the simulation approach. By integrating the actual avionic device into the trainer and loading the actual Operational Flight Program (OFP) into it, operational fidelity can be maintained by installing new software on the simulator at the same time it is fielded to the aircraft. However, new difficulties are introduced when the prime hardware incorporation approach is employed. The device is often costly and in short supply, especially during the early phases of an aircraft development or update. All signal interfaces of the device must be met, which often introduces a need for custom designed interface hardware such as special serial buses and the like.
Additionally, it has been noted that avionic devices designed for two or four hour flight missions often exhibit reduced reliability during eighteen or twenty-four hour training schedules. In other words, the work load placed upon the hardware in the environment of a flight simulator is generally greater than that placed upon it in actual flight operations, for flight operations often occur in short time spans over long periods of time, whereas a flight simulator is often employed for extended durations approaching full time operation.
Most significantly with respect to the prime hardware incorporation approach is the fact that implementation of SSF's requires modifications to the OFP, which can create logistical difficulties since the avionics OFP and simulator are seldom written and maintained by the same contractor. A very awkward interaction must be supported whereby the avionics integrator must implement functions which it does not understand, which may add great complexity to its task, and for which it has no good test methodology. Typically, avionics designers are extremely hesitant to implement such functions.